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                         SMTP Service Extension
                         for 8bit-MIMEtransport

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

1.  Abstract

   This memo defines an extension to the SMTP service whereby an SMTP
   content body containing octets outside of the US ASCII octet range
   (hex 00-7F) may be relayed using SMTP.

2.  Introduction

   Although SMTP is widely and robustly deployed, various extensions
   have been requested by parts of the Internet community. In
   particular, a significant portion of the Internet community wishes to
   exchange messages in which the content body consists of a MIME
   message [3] containing arbitrary octet-aligned material. This memo
   uses the mechanism described in [5] to define an extension to the
   SMTP service whereby such contents may be exchanged. Note that this
   extension does NOT eliminate the possibility of an SMTP server
   limiting line length; servers are free to implement this extension
   but nevertheless set a line length limit no lower than 1000 octets.

3.  Framework for the 8bit MIME Transport Extension

   The 8bit MIME transport extension is laid out as follows:
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          (1)  the name of the SMTP service extension defined here is
               8bit-MIMEtransport;

          (2)  the EHLO keyword value associated with the extension is
               8BITMIME;

          (3)  no parameter is used with the 8BITMIME EHLO keyword;

          (4)  one optional parameter using the keyword BODY is added to
               the MAIL FROM command.  The value associated with this
               parameter is a keyword indicating whether a 7bit message
               (in strict compliance with [1]) or a MIME message (in
               strict compliance with [3]) with arbitrary octet content
               is being sent. The syntax of the value is as follows,
               using the ABNF notation of [2]:

                    body-value ::= "7BIT" / "8BITMIME"

          (5)  no additional SMTP verbs are defined by this extension;
               and,

          (6)  the next section specifies how support for the extension
               affects the behavior of a server and client SMTP.

4.  The 8bit-MIMEtransport service extension

   When a client SMTP wishes to submit (using the MAIL command) a
   content body consisting of a MIME message containing arbitrary
   octet-aligned material, it first issues the EHLO command to the
   server SMTP. If the server SMTP responds with code 250 to the EHLO
   command, and the response includes the EHLO keyword value 8BITMIME,
   then the server SMTP is indicating that it supports the extended MAIL
   command and will accept MIME messages containing arbitrary octet-
   aligned material.

   The extended MAIL command is issued by a client SMTP when it wishes
   to transmit a content body consisting of a MIME message containing
   arbitrary octet-aligned material. The syntax for this command is
   identical to the MAIL command in [1], except that a BODY parameter
   must appear after the address.

   The complete syntax of this extended command is defined in [5]. The
   esmtp-keyword is BODY and the syntax for esmtp-value is given by the
   syntax for body-value shown above.

   The value associated with the BODY parameter indicates whether the
   content body which will be passed using the DATA command consists of
   a MIME message containing some arbitrary octet-aligned material
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   ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").

   A server which supports the 8-bit MIME transport service extension
   shall preserve all bits in each octet passed using the DATA command.

   Naturally, the usual SMTP data-stuffing algorithm applies so that a
   content which contains the five-character sequence of

               <CR> <LF> <DOT> <CR> <LF>

   or a content that begins with the three-character sequence of

               <DOT> <CR> <LF>

   does not prematurely terminate the transfer of the content.  Further,
   it should be noted that the CR-LF pair immediately preceeding the
   final dot is considered part of the content.  Finally, although the
   content body contains arbitrary octet-aligned material, the length of
   each line (number of octets between two CR-LF pairs), is still
   subject to SMTP server line length restrictions (which may allow as
   few as 1000 octets on a single line).

   Once a server SMTP supporting the 8bit-MIMEtransport service
   extension accepts a content body containing octets with the high-
   order (8th) bit set, the server SMTP must deliver or relay the
   content in such a way as to preserve all bits in each octet.

   If a server SMTP does not support the 8-bit MIME transport extension
   (either by not responding with code 250 to the EHLO command, or by
   not including the EHLO keyword value 8BITMIME in its response), then
   the client SMTP must not, under any circumstances, attempt to
   transfer a content which contains characters outside the US ASCII
   octet range (hex 00-7F).

   A client SMTP has two options in this case: first,  it may implement
   a gateway transformation to convert the message into valid 7bit MIME,
   or second, or may treat this as a permanent error and handle it in
   the usual manner for delivery failures.  The specifics of the
   transformation from 8bit MIME to 7bit MIME are not described by this
   RFC; the conversion is nevertheless constrained in the following
   ways:

          (1)  it must cause no loss of information; MIME transport
               encodings must be employed as needed to insure this is
               the case, and

          (2)  the resulting message must be valid 7bit MIME.
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5.  Usage Example

   The following dialogue illustrates the use of the 8bit-MIMEtransport
   service extension:

          S: <wait for connection on TCP port 25>
          C: <open connection to server>
          S: 220 dbc.mtview.ca.us SMTP service ready
          C: EHLO ymir.claremont.edu
          S: 250-dbc.mtview.ca.us says hello
          S: 250 8BITMIME
          C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
          S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
          C: RCPT TO:<mrose@dbc.mtview.ca.us>
          S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
          C: DATA
          S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
           ...
          C: .
          S: 250 OK
          C: QUIT
          S: 250 Goodbye

6.  Security Considerations

   This RFC does not discuss security issues and is not believed to
   raise any security issues not already endemic in electronic mail and
   present in fully conforming implementations of [1].
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